一、背景

DNS協議提供了域名與IP地址轉換的服務，是必不可少的網絡通信協議之一，也是整個互聯網運行的基礎。然而，傳統的流量檢測設備很少對DNS協議傳輸數據的有效性、安全性進行深度分析和檢查。思科在其安全研究報告中形象地稱之為“DNS盲點”。惡意軟件正是利用此機會，通過DNS協議構建隱蔽隧道，進而實現命令控制C&C、數據外發等攻擊。EfficientIP發布的《全球DNS威脅報告2018》指出，2018年77%的組織至少經歷過一次基于DNS的網絡攻擊，并且DNS隧道占據了絕大比例。DNS隱秘隧道技術是MITRE ATT&CK命令與控制矩陣(Command and Control）中的子技術，其ID為T1071.004。ATT&CK中記錄有30多個目前已知的APT工具使用DNS隧道實施C&C攻擊，比如：OilRig組織使用的Helminth和ISMAgent、OceanLotus使用的Denis等。

當前，針對DNS隧道的檢測方法很多，如基于閾值、統計或專家規則的方法以及基于機器學習的方法等。實踐證明，相比其他類方法，基于機器學習的DNS隧道檢測方法在檢測效果、防繞過、泛化能力等方面具有較大的優勢。

本文將從DNS隧道基礎知識、DNS隧道檢測方法現狀及DNS隧道檢測實踐三個方面介紹相關內容。

二、DNS隧道基礎知識

2.1 DNS隧道簡介

DNS隧道是一種隱蔽隧道，即通過將數據或命令封裝到DNS協議進行數據、命令等傳輸的隧道，DNS隧道提供了宿主機與其C&C服務器之間低速但隱蔽的雙向通信通道。

DNS隧道從用途上可以分為定時隱蔽隧道和存儲隱蔽隧道兩種。前者使用定時屬性將相同結構的DNS請求發送到C&C，這類消息通常為心跳；而后者則使用DNS協議封裝編碼的信息，這類信息通常為傳輸的敏感數據。與定時隱蔽隧道相比，存儲隱蔽隧道可以提供更高的帶寬，因此存儲隱蔽隧道使用更為廣泛。無論哪種隧道類型都使用DNS請求的子域將數據傳輸到C&C，并使用這些請求的響應從C&C接收數據。因此，DNS隧道中傳輸的數據必須遵守DNS協議規范，請求的域名必須具有label，并且必須以字母或數字開頭和結尾，每個label的長度不超過63個字符，整個域名的長度不超過255個字符。

2.2 DNS隧道原理

DNS隧道在通信方式上又分為直連和中繼兩種模式。直連是宿主機直接與指定的目標DNS Server(Authoritative NS Server)連接，通過將編碼數據封裝在DNS協議中進行通信。這種方式速度快，但是隱蔽性比較差，很容易被探測到，另外限制比較多，很多場景不允許自己指定DNS Server。而通過DNS迭代查詢實現的中繼隧道則更為隱蔽，但同時因為數據包到達目標DNS Server前需要經過多個節點，所以速度上比直連慢。

中繼DNS隧道工作原理如圖1[1]所示，具體如下：

Step1: 攻擊者首先注冊一個域名，如ex.fil，域名指向攻擊者控制的服務器，并在該服務器上安裝惡意隧道服務器端程序。

Step2: 攻擊者利用惡意軟件感染公司內網中的主機，之后受感染主機向DNS解析服務器發送請求，DNS解析服務器將請求中繼到根域名服務器和頂級域服務器。

Step3: 各級DNS解析服務器最終將請求路由到被攻擊者控制的安裝了隧道程序的C&C服務器。

最終宿主機和C&C之間通過DNS解析服務器建立了連接，并使用該隧道泄露數據或實現其他惡意目的。由于宿主機和C&C之間沒有直接連接，因此追蹤攻擊者更加困難。

圖 1 DNS隧道原理

2.3 DNS隧道工具

目前有很多開源DNS隧道工具，比如：iodine、DNSCat2、dns2tcp等等，我們稱之為通用DNS隧道工具。這些工具開源并且支持二次開發，例如基于Iodine開發的Android DNS隧道工具MagicTunnel，它們支持多種平臺、語言以及記錄類型。

很多APT組織使用的惡意軟件也具有DNS隧道功能，我們稱之為APT工具。相對于通用DNS隧道工具，很多APT工具支持特定的硬編碼命令，其數據封裝更精巧，支持的記錄類型更廣泛，檢測也更加困難，比如很多APT工具支持A和AAAA記錄類型。

表 2 具有DNS隧道功能的APT工具

2.4 典型DNS隧道樣例

DNS隧道的使用非常廣泛，除了一些通用的開源DNS隧道工具之外，很多APT工具也使用了DNS隧道技術。接下來將對部分通用DNS隧道工具和APT工具進行舉例說明。

2.4.1 Iodine

Iodine是基于C語言實現的開源DNS隧道工具。Iodine在默認情況下使用NULL記錄類型，同時可以支持PRIVATE、TXT、SRV、MX、CNAME和A（返回CNAME）類型。Iodine在外發數據時首先會使用GZIP對數據進行壓縮然后再編碼發送，其支持Base32、Base64和Base128編碼。

2.4.2 Dns2tcp

Dns2tcp也是基于C語言實現的開源DNS隧道工具，并且已預裝在Kali Linux和BlackArch Linux系統。在默認情況下，Dns2tcp使用TXT記錄類型，但它也可以支持KEY記錄類型。在通信時雙向數據都使用Base64編碼進行傳輸。

2.4.3 Dnscat2

Dnscat2是基于JAVA實現的開源DNS隧道工具。Dnscat2可以使用TXT、CNAME和MX記錄類型，但是如果僅將數據從客戶端發送到服務端時它還支持A和AAAA記錄類型。在通信時雙向數據均使用十六進制編碼進行傳輸。

2.4.4 ISMAgent

ISMAgent是OilRig組織所使用的具有DNS隧道功能的惡意軟件。通過Wireshark抓包展示ISMAgent發送初始信標并將數據發送到C&C服務器的過程。首先木馬使用DNS請求向C&C發送包含會話ID的初始信標，C&C使用特定的IPv6地址作為響應指示隧道建立連接，然后木馬繼續發送包含數據編號、隨機數和編碼數據的DNS請求，C&C使用特定IPv6響應這些請求以指示木馬繼續發送數據直到所有數據都發送到C&C服務器，C&C使用包含請求數的IPv6響應以指示數據傳輸完畢。

2.4.5 Helminth

Helminth是OilRig組織在攻擊活動中開發的具有DNS隧道功能的惡意軟件。Helminth有兩種版本，一種是可執行可移植的版本，另一種是Power Shell版本，這兩種版本都通過DNS隧道與C&C進行通信。兩個版本的DNS隧道運行方式相同，僅對生成的子域進行更改，使它們看起來不同以逃避檢測。

Helminth PowerShell接收C&C指令的過程如下：首先，Helminth木馬發出DNS請求啟動與C&C服務器的會話，C&C用IPv4地址響應此信標，木馬從該IPv4中獲得唯一的系統標識符；然后Helminth發送帶有系統標識的DNS請求，C&C用一個IPv4地址來響應該請求，Helminth將IPv4轉換為字符作為下載腳本的文件名；最后，Helminth繼續發出其他的DNS請求，并將響應中的IPv4視為命令寫入腳本文件，C&C以特定IPv4響應以指示命令傳輸完畢。

Helminth PowerShell外發數據的過程如下：當收到指示IPv4后，Helminth執行腳本同時將執行結果寫入到與腳本同名的文本文件中，最后該文件通過DNS請求發送到C&C，C&C以固定的IPv4響應。

2.4.6 Denis

Denis是Ocean Lotus組織最常用的特種木馬，是一個全功能的后門，攻擊者使用DNS隧道實現了一種更加隱秘的C&C通信方法。為了確保DNS流量不被過濾，攻擊者將后門配置為與Google和OpenDNS 的DNS服務器通信，因為大多數組織和安全產品都不會過濾發送到到這兩個主要DNS服務器的流量。

Denis首先向Google DNS服務器發送包含會話ID的初始信標，并由各級域名服務器路由到攻擊者控制的C&C服務器以建立連接，然后C&C以數據字節數和硬編碼指令響應該請求，Denis接收到響應后執行特定的命令并將命令執行結果通過Google DNS服務器發送到C&C。Denis總共支持16條硬編碼指令，大多數指令涉及與被攻擊計算機文件系統的交互，另外還具有獲取有關打開窗口的信息、調用任意API和獲取有關系統簡要信息的功能。

三、DNS隧道檢測現狀

目前業界提出了各種DNS隧道檢測方法，總體來說可以分為兩類：一類為基于規則的檢測方法，一類為基于機器學習的檢測方法。

基于規則的方法是通過閾值來識別DNS隧道，比如監控終端請求域名的長度，如果域名長度超過設定閾值，則會發出警報。此外，尋找不常用的DNS記錄類型（例如TXT、NULL記錄）是另一種常用的檢測方法[3]。基于閾值的檢測方法不夠靈活、泛化能力差，并可以通過修改域名長度、請求頻率等特征輕易繞過檢測。

基于機器學習的方法通過學習歷史數據特征，可以準確地識別未知的DNS隱蔽隧道，同時兼具誤報率低、不易被繞過等優點。基于機器學習的DNS隧道檢測方法可以總結為兩類：一類為負載分析，這類方法是受DGA檢測研究的啟示[4]，主要關注DNS負載的隨機性、字符頻率等特征；另一類為基于時間窗口的流量分析，這類方法關注DNS請求或響應隨著時間變化的統計特征，包括時間窗內每個域名的主機名數量、各種記錄類型（A、AAAA、TXT等）的頻率、子域N-Gram均值和方差、請求和響應時間間隔的均值和方差等等。

文獻[5]根據齊夫定律提出了NgViz方法，該方法使用多條正常DNS流量統計其負載的字符頻率以及字符排名，在推理階段計算輸入的多條DNS請求與正常DNS流量的字符排名和字符頻率的加權匹配度，通過既定的閾值來判別DNS隧道，但該方法檢測效果不佳。文獻[6]使用DNS請求和響應負載的字符熵和長度以及DNS數據包包長等特征構建隨機森林模型，該實驗表明使用DNS請求和響應特征比單獨使用請求或響應的特征檢測準確率更高，但是該方法對于未知隧道工具召回率較低，且只能檢測使用TXT、NULL等記錄類型的隧道工具，無法檢測使用A、AAAA記錄類型的新型隧道工具。文獻[7]使用DNS請求的七個特征，包括FQDN中的字符總數、子域中字符數、大寫字母和數字字符的數量、字符熵以及DNS請求域名的最大標簽長度和平均標簽長度特征構建孤立森林模型以檢測DNS隧道。這種方法不涉及任何特定的DNS記錄類型，但由于使用無監督的模型，該方法召回率較低。文獻[8]使用DNS請求和響應的統計特征，例如：DNS請求和響應負載的平均長度、編碼的有效載荷和唯一請求的數量等，該方案也使用孤立森林算法，但是該方法僅考慮A和AAAA兩種記錄類型，而且在實驗中也僅考慮了Iodine和dns2tcp兩個開源隧道工具。文獻[9]指出，DNS隧道用于在宿主機和C&C交換數據時，通常將編碼數據封裝到DNS請求和響應的負載部分。作者提出了兩種基于機器學習的方法：(i)邏輯回歸模型和(ii) k-means聚類，這兩種方法都是從編碼的有效載荷中提取語法特征，例如：字符熵和字符（大寫、小寫、數字、破折號）數量，但是該方案也僅僅針對使用TXT記錄的隧道工具dnscat2。文獻[10]分析了幾個開源DNS隧道工具的流量，提取了四種類型的特征：請求和響應時間間隔的均值和方差、請求數據包大小、域名熵和記錄類型（例如A、TXT、MX等）比例等特征。作者使用了多個DNS隧道工具生成的數據訓練分類模型，但測試數據仍然是由參與訓練的隧道工具產生。

四、DNS隧道檢測實踐

現有的基于機器學習的DNS隧道檢測方案使用多種DNS隧道工具生成的數據訓練模型，以使模型可以識別更多的隧道工具，但是這種方案對未參與訓練的隧道工具和未知隧道工具的檢測效果不佳，也即模型泛化性能差；另外，在缺少多種隧道工具數據的現狀下，一些方案為了提高模型的泛化能力使用統計分析的方法，但這種方案無法實現實時檢測。基于對上述兩個問題的考慮，本文提出了僅使用DNS請求特征的DNS隧道實時檢測方案，

方案分為四個模塊：第一個模塊為數據處理模塊，該模塊主要是解析DNS流量數據并提取相關字段內容；第二個模塊為特征提取模塊，該模塊基于數據處理模塊的結果創建并提取DNS隧道檢測相關的特征；第三個模塊為模型訓練模塊，該模塊使用提取的相關特征訓練機器學習模型，對模型進行調優并持久化；第四個模塊為模型推理模塊，該模塊加載已經訓練好的模型并對未知DNS流量進行推理預測。

4.1 特征創建

DNS隧道通過DNS請求的負載攜帶編碼或加密數據，其很多特征的分布均與正常DNS請求有差異，接下來將通過部分特征來分析DNS隧道。

4.1.1 子域長度

正常域名每個label的長度不超過63個字符，整個域名的長度不超過255個字符，正常域名長度往往遠不及255個字符，但DNS隧道為了增加帶寬，其負載往往會攜帶更多的信息。其次由于DNS隧道通常會對數據進行編碼，因此其長度比正常域名更長。

4.1.2 最大label長度

與子域長度特征一樣，由于DNS隧道負載攜帶更多的數據，因此與正常域名相比其每個label都較長。

4.1.3 字符比例

大寫小寫字母、數字、特殊字符等在域名中所占的比例也是區分正常或隧道的重要特征。因為DNS隧道在傳輸數據之前往往使用base32、base64、自定義加密算法等對數據進行編碼或加密，因此負載中大寫字母和數字的比例較高，但正常域名不區分大小寫，其幾乎不含有大寫字母，且域名中數字所占比例也較低。

4.1.4 連續字符比例

由于DNS隧道負載為編碼數據，因此其連續數字、連續輔音的比例與正常域名有較大的差異。

4.1.5 熵

編碼的DNS隧道會使用更廣泛的字符，其字符分布的熵值更高。然而正常域名有較高的可讀性，其字符分布與正常英文語料一致，熵值相對較低。因此n-gram熵被視為可以指示DNS隧道活動的重要因素之一。

4.1.6 字符轉移概率

基于正常域名可讀性的特征，可以使用正常DNS流量或者英文語料統計N-Gram的轉移概率。對于DNS隧道負載，其編碼后的數據更隨機，N-Gram轉移概率與正常語料差異較大。因此N-Gram轉移概率也是區分正常DNS和隧道的重要特征。

4.2 模型

通過分析各隧道工具生成樣本的特征向量，各隧道工具生成的黑樣本在各特征上均與白樣本存在顯著差異，但不同隧道工具樣本之間也存在顯著差異。因此需要對所使用的特征進行一系列優化，否則模型僅能檢測出參與模型訓練的隧道工具生成的數據，也就是說模型泛化能力差，不能發現未知隧道工具的數據。為了驗證本文所述方法，訓練集僅使用一種隧道工具產生的數據，通過檢測未參與訓練的隧道工具數據來測試模型的泛化能力。經過調節參數后模型達到最好的檢測效果，模型在驗證集AP 為 100%。

4.3 模型評估

目前的方案對檢測參與訓練的隧道工具都具有較高的準確率和召回率，但是對于未參與訓練的工具或者未知工具的隧道數據檢測效果較差。為了驗證本文所述方案對于參與訓練和未知工具隧道數據的檢測效果，對多個通用開源DNS隧道工具和APT工具進行單獨測試，最終檢測結果顯示本方案所述模型可以檢測絕大多數的通用開源DNS隧道工具和APT隧道工具，而未檢出的樣本均為定時隱蔽隧道數據。具體檢測效果如下：

五、 總結

基于機器學習的DNS隧道檢測優于傳統基于閾值、統計或專家規則的方法。本文提出的基于機器學習的DNS隧道檢測方案優于同類方案，僅通過DNS請求的負載部分進行DNS隧道檢測，同時對使用的特征進行了多項優化，可以支持多種工具和多種記錄類型。當然，所提出的方案對于檢測定時隱蔽隧道還有局限性，后續將進一步完善方案以適應更多場景。

參考文獻

[1] Nadler A , Aminov A , Shabtai A . Detection of malicious and low throughput data exfiltration over the DNS protocol[J]. Computers & Security, 2019.

[2] Robert Falcone. DNS Tunneling in the Wild: Overview of OilRig’s DNS Tunneling[Online].https://unit42.paloaltonetworks.com/dns-tunneling-in-the-wild-overview-of-oilrigs-dns-tunneling/,2020.

[3] S. Jaworski. Using splunk to detect dns tunneling[J]. SANS Institute InfoSec Reading Room, 2016.

[4] L. Bilge, E. Kirda, C. Kruegel, and M. Balduzzi. Exposure: Finding malicious domains using passive dns analysis[J]. NDSS,2011.

[5] K.Born, D.Gustafson.NgViz:detecting DNS tunnels through N-gram visualization and quantitative analysis[A]. Proceedings of the Sixth Annual Workshop on Cyber Security and Information Intelligence Research[C]. Oak Ridge, Tennessee, 2010. 1-4.

[6] A. Berg and D. Forsberg, "Identifying DNS-tunneled traffic with predictive models", Jun. 2019, [online] Available: http://arxiv.org/abs/1906.11246.

[7] M. Lyu, H. Habibi Gharakheili, C. Russell. “Mapping an Enterprise Network by Analyzing DNS Traffic,” in Proc. Passive and Active Measurement (PAM), Puerto Varas, Chile, Mar 2019.

[8] A. Nadler, A. Aminov, and A. Shabtai. Detection of malicious and low throughput data exfiltration over the dns protocol. Computers & Security, 80:36–53, 2019.

[9] A. Das, M.-Y. Shen, M. Shashanka, and J. Wang. Detection of exfiltration and tunneling over dns. In Machine Learning and Applications (ICMLA), 2017 16th IEEE International Conference on, pages 737–742. IEEE, 2017.

[10] J. Liu, S. Li, Y. Zhang, J. Xiao, P. Chang, and C. Peng. Detecting dns tunnel through binary-classification based on behavior features. In Trustcom/BigDataSE/ICESS, 2017 IEEE,pages 339–346. IEEE, 2017.

版權聲明

轉載請務必注明出處

版權所有，違者必究